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Chapter 1 

Introduction 



This chapter briefly presents the purpose and the scope of the work on the 
Ftkhpse project with a subset of relevant definitions and acronyms. All 
these aspects are detailed to some extent later through the document. 

1.1 Purpose 

To design and implement a plugin-bascd environment that allows to inte- 
grate forensic tools working together to support programming tasks and 
addition of new tools. Integration is done through GUI components. 

1.2 Scope 

The end-product enviroment must have user friendly GUI, configuration ca- 
pabilities, plug-in capabilities to insert/inject new tools, case management, 
and chain of custody capabilities, along with evidence gathering capabilities, 
evidence preservation capabilities, and, finally report generation capabilities. 
A subset of these requirements has been implemented in Ftklipse, which is 
detailed throughout the rest of this document. 
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1.3 Definitions and Acronyms 

Cryptographic Hash Function Function mapping input data of an arbri- 
tary size to a fixed-sized output that is highly collision resistant. 

Digital evidence Information stored or transmitted in binary form that 
may be relied upon in court. 

dcf Idd Enhanced DD imager with built-in hashing, works like dd from com- 
mand line. 

Hashing on-the-fly dcf Idd can hash the input data as it is being 
transferred, helping to ensure data integrity. 

Status output dcf Idd can update the user of its progress in terms 
of the amount of data transferred and how much longer operation 
will take. 

Flexible disk wipes dcf Idd can be used to wipe disks quickly and 
with a known pattern if desired. 

Image/wipe verify dcf Idd can verify that a target drive is a bit- 
for-bit match of the specified input file or pattern. 

Multiple outputs dcf Idd can output to multiple files or disks at the 
same time. 

Split output dcf Idd can split output to multiple files with more 
configurability than the split command. 

Piped output and logs dcf Idd can send all its log data and output 
to commands as well as files natively. 

Documentation Written notes, audio/ videotapes, printed forms, sketches, 
and/or photographs that form a detailed record of the scene, evidence 
recovered, and actions taken during the search of the scene. 

JVM The Java Virtual Machine. Program and framework allowing the ex- 
ecution of program developped using the Java programming language. 
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Magnetic media A disk, tape, cartridge, diskette, or cassette that is used 
to store data magnetically. 

Steganography It simply takes one piece of information and hides it within 
another. Computer files (images, sounds recordings, even disks) con- 
tain unused or insignificant areas of data. Steganography takes ad- 
vantage of these areas, replacing them with information (encrypted 
mail, for instance). The files can then be exchanged without anyone 
knowing what really lies inside of them. For example, an image of 
the space shuttle landing might contain a private letter to a friend. A 
recording of a short sentence might contain your company's plans for a 
secret new product. Steganography can also be used to place a hidden 
"trademark" in images, music, and software, a technique referred to 
as watermarking. 

SWT The Standard Widget Toolkit ^Con06c| , a set of graphical user inter- 
face components provided by the Eclipse framework. 

Temporary and swap files Many computers use operating systems and 
applications that store data temporarily on the hard drive. These files, 
which are generally hidden and inaccessible, may contain information 
that the investigator finds useful. 
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System Overview 



In this chapter, we examine the architecture of our implementation of Ftk- 
Hpse. We first introduce our architectural philosophy before informing the 
reader about the Siemens Four View Model, an architectural methodology 
for the conception of large-scale software systems. Afterwards, we exam- 
ine each of the view, as architected for our system. Finally, we conclude 
with other software engineering matters that were of high importance in the 
development of our implementation. 

2.1 Architectural Strategies 

Our principles are: 

Platform independence We target systems that are capabale of running 
a JVM. 

The Eclipse plug-in based environment slightly imitating the MVC (Model- 
view -Controller) pattern, to map the traditional input, processing, 
output roles into the GUI realm. In Eclipse model, a plug-in may be 
related to another plug-in by one of two relationships: 

Dependency The roles in this relationship are dependent plug-in and 
prerequsite plug-in. A prerequisite plug-in supports the function 
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of a dependent plug-in. 

Extension The roles in this relationship are host plug-in and extender 
plug-in. An extender plug-in extends the functions of a host plug 
-in. 

Database independent API will allows us to swap database engines on- 
the-fly. 

Resisonable Efficiency We will architect and implement an efficient sys- 
tem, but will avoid advanced programming tricks that improve the 
efficiency at the cost of maintainability and readability. 

Simplicity And Maintainability Wc will target a simplistic and easy to 
maintain organization of the source. 

Architectural Consistency We will consistently implement our architec- 
tural approach. 

Sepsiration of Concerns We will isolate separate concerns between mod- 
ules and within modules to encourage reuse and code simplicity. 



2.2 System Architecture 

2.2.1 Module View 

Layering 

We divided our application between layers. The top level has a front-end and 
a back-end. The frontcnd comprised a collection of GUI modules provided 
by and customized from eclipse as well as custom-dcsignd by the team. 
The backend consists of supporting functionality and specifically database 
management, report generation, and external tool invocation. 
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Interface Design 

Several interfaces had to be designed for tlie arcliitecture to work All the 
backend modules have an interface they expose to the frontend to use. Thus, 
there are interfaces between, GUI-to-External- Tools, GUI-to-Database, and 
GUI-to-Report-Generation. All these are designed to be swappable and 
highly modular so any component series can be replaced at any time with lit- 
tle or no change to the code. The interfaces (FtklipseCommonDatabaseBridge 
and IDatabaseAdapter, ITool and IToolExecutor, and IReportGenerator 
and ReportGeneratorFactory) are presented in the detiled design chapter. 

2.3 Execution View 

2.3.1 Runtime Entities 

In the case of our application, there is hosting run-time environment that 
of Eclipse. The application can run within Eclipse IDE or be a stand-alone 
with a minimal subset of the Eclipse run-time. By nature, a JVM machine 
is executing all the environment and all GUI-based applications are multi- 
threaded to avoid blockage on user's input. Additionally, depending on the 
database engine used behind the scenes, it may as well be multi-threaded to 
provide concurrent access and connection pooling. 

2.3.2 Communication Paths 

It was resolved that the modules would all communicate through message 
passing between methods. Communication to the database depends on the 
database adapter, and in our sample implementation is done through and 
in-process JDBC driver. Additionally, Java's reflection is used to discover 
instantiation communication paths at run-time for pluggable modules. 
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2.3.3 Execution Configuration 

Execution configuration in Ftklipse has to do with where its data directory 
is. The data directory is always local to where the application was ran from. 
The directory contains the main case database in the ftklipsedb.* files 
as well as numerical directorys with case ID with imported evidence files. 
Additionall configuration for application is located in plugin. properties 
and plugin. xml files. 



2.4 Coding Standards and Project Management 

In order to produce high-quality code, we decided to normalize on the 
OpenBSD style. We also decided to use javadoc source code documen- 
tation style for its completeness and the automated tool support. We used 
Subversion (svn) |Col07] in order to manage the source code, makefile, and 



documentation revisions provided by SourceForge . net 
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Detailed System Design 



• Case management: Investigations are organized by cases, which can 
contain one or more evidences. Each evidence can contain one or more 
file system images to analyze; 

• Evidence Gathering using integrated and plug- in tools; 

• Evidence Integrity validation using a hash function; 

• Evidence Import from any media to an existing case; 

• Logging of all operations performed on the evidence; 

• Validation of integrity of evidence after each operation over it; 

• Display of evidence in read-only mode either in ASCII, Unicode or 
Hex formats; 

• Recording of investigative notes for each piece of evidence; 

• Capability to extract a part of the evidence into another file; 

• Capability to copy and rename the copy of the evidence; 

• Generation of reports in PDF and I^'l^jX2e formats that includes listing 
of the evidence in the case, a printout of selected parts of the evidence. 
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the investigative notes related to selected parts of the evidence and 
a customized executive summary, introduction, and conclusion. It 
also integrates the chain of custodity information for each part of the 
evidence displaying the principal, timestamp and operation performed 
on the evidence. 

• An extendable set of tools through a plug-in architecture; 

• General as well as tool-specific defaults and configuration screens; 



3.1 Class Diagrams 

We have a number of class diagrams representing the majore modules and 
their relationships. Please located the detailed descriprion of the modules 
in the generated HTML of javadoc or the javadoc comments themeselves in 
the doc/ javadoc directory. 



The basic UI classes are in Figure 3.1 The prototype internal access 
control classes are in Figure |3.2[ The main database abstraction is in Fig- 
ure 



3.3 Next, concrete database adatpters are in Figure ??. Further, the 
database- and Ul-indepedent database objects data structures are in Fig- 
ure 



3.5 The report generation- related API is in Figure |3.6[ Finally, the 



external tools invocation framework is in Figure 3.7 



3.2 Data Storage Format 

This section is about data storage issues and the details on the chosen un- 
delying implementation and ways of addressing those issues. 



3.2.1 Entity Relationship Diagram 



The ER diagram of the underlying SQL engine we chose is in Figure 3.8 



The database is pretty simple as the case.data field is a BLOB to which 
the Case data structure is serialized. The id.count table is simply there to 
contain the maximum ID used accros the database objects in the application. 
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Figure 3.1: Class Diagram for the basic User Interface 
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Figure 3.2: Class Diagram for Access Control Framework 



It is updated on application close, so when the application is loaded back 
again, it sets its internal ID from the database properly for newly created 
cases and other objects. 

The database is slatted for extension with some code map data for the 
UI as well as log facilities later on for better reporting, like who, what, when, 
etc. 

3.2.2 External Systems and Databases 

The database engine the Ftklispe application talks to is abstracted away so 
that the actual engine particularities (e.g. SQL queries or XML atoms) are 
not visible to the application thus making it database-engine independent. 
The provision was made to have SQL, XML, JavaSpaces |Mam05) , or raw 
object serialization databases. The actual external database engine used in 
the demo version of the toolkit, is the HSQLDB |The08] database, which 
is implemented in Java itself and has an in-process execution capability. 
This database engine is started automatically within the same process as an 
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Figure 3.3: Class Diagram for the Database Root Package 
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Figure 3.4: Class Diagram for the Database Adapters 
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Figure 3.5: Class Diagram for the Database Objects 
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Figure 3.6: Class Diagram for the Report Generation 
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Figure 3.7: Class Diagram for the Backend Tools Framework 
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Figure 3.8: Simple ER Diagram of the Internal Database 



application when a first connection is made. It is shudown when application 
exits. This choice is justified by simplicity and does not require an external 
database server to be set up. This external implementation of the engine is 
in lib/hsqldb. jar. 

The database-produced files are stored in the data directory relative to 
the current execution environment. The files are ftklipsedb .properties 
and ftklipsedb . script. The former describes the global database settings 
and the latter is the serilized database itself, including DDL DML statements 
to reproduce the database. Both are managed by the HSQLDB engine itself. 
Originally when deploying the application, neither may present. They will 
be created if not present when Ftklipse starts. 

Another external system we rely on in the form of library is the PDF 
generation library iText |LS06| |LS06j . which is in lib/itext . jar. This 
library is used in PDFReportGenerator to produce a PDF copy of the case 
data stored in the database. 

3.2.3 Log File Format 

The log is saved in the ftklipse . application . log. As of this version, the 
file is produced with the help of the Logger class that has been imported 
from MARF |The09| . (Another logging facility that was considered but 
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not yet implemented is the Log4J tool |AGS"'"06 , which has a full-fledged 



logging engine.) The log file produced by Logger has a classical format of 
[ time stamp ] : message. The logger intercepts all attempts to write to 
STDOUT or STDERR and makes a copy of them to the file. 

3.3 Directory and Package Organization 

In this section, we introduce the reader to the structure of the folders for 
ftklipse. Please note that Java, by default, converts sub-packages into sub- 



folders, which is what we see in Figure 3.9 



Please also refer to Table |3.1| and Table 3.2 for description of the data 



contained in the folders and the package organization, respectively. 

3.4 Plug-Ins 

In order to allow tools to be plugged in, we use Eclipse's default mechanism, 
which requires to define and export and extension point. The extension point 



Table 3.4 defines a set of properties that are mostly used to populate the 
user interface as well as providing the interfaces that must be implemented 
in order to contribute a plug-in to ftklipse. 

Any third party can contribute a plug-in tool in ftklipse by creating 
an Eclipse plug-in project that chooses to extend ca. concordia. ciise . 
ftklipse . f tklipse_tools. Those plug-ins can afterwards be installed man- 
ually in the Eclipse folder's sub-root, or using Eclipse's built-in installer and 
updater. When installed properly, ftklipse will detect them without the 
need to update any configuration file or perform other similar adminsitra- 
tive works. 

Each plug-in is responsible for implementing its own dialog(s) and may 
optionally define its own parameters persistence mechanism, although our 
API strongly sugests the use of Eclipse's technology to do so. 

In order that all tools can have access to information from the user 
interface, and that the user interface can have access to information about 
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Folder 


Description 


bin 


Directory containing the compiled files. All package 
names described here are also present under this di- 
rectory. 


data 


Directory containing the case database as well as sub- 
directories for each of the cases. 


doc 


Project's documentation 


example .evidence 


Demo evidence that can be used in the projects 


icons 


icons useable for branding and decorating the appli- 
cation 


lib 


External libraries used by ftklipse 


META-INF 


Project's meta-information that would be included in 
a JAR bundle 


references 


Some useful references on the web on Eclipse devel- 
opment 


schema 


Project's extension point definitions 


src 


Directory containing the source code files. All pack- 
age names described here are underneath this direc- 
tory 


tools 


Precompiled tools to use. Also organized hierarchi- 
cally. 



Table 3.1: Details on folder structure 
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Package 


Description 


ca.concordia.ciise.ftklipse 


Ftklipse's root package 
name 


ca.concordia.ciise.ftklipse.accesscontrol 


Ftklipse's access con- 
trol model 


ca.concordia.ciise.ftklipse.database 


b tklipse s database 
module 


ca.concordia.ciise.ftklipse.database.adapters 


Database adapters 


ca.concordia.ciise.ftklipse.database.connection 


Database connection 
objects 


ca.concordia.ciise.ftklipse.database.objects 


Object model that is 
saved and restored 
from the database 


ca.concordia.ciise.ftklipse. database. reporting 


Reporting sub-module 


ca.concordia.ciise.ftklipse.database.util 


Database utility 
classes 


ca. Concordia. ciisc.ftklipsc.j unit 


Some JUnit tests 


ca.concordia.ciise.ftklipse.tools 


Tool execution mod- 
ule, not including GUI 
screens 


ca. concordia.ciise .ftklipse .tools . executors 


Tool execution 
adapters for the 
underlying platform 


ca. concordia.ciise .ftklipse .tools . linux 


Tool adapters for 
Linux tools 


ca.concordia.ciise.ftklipse.tools.windows 


Tool adapters for Win- 
dows tools 


ca.concordia.cnse.ftklipse.ui 


Ftklipse s user inter- 
face classes 


ca.concordia.ciise.ftklipse.ui.actions 


Eclise actions for the 
menu and right-click 
menu 


ca.concordia.ciise.ftklipse.ui.tools 


User interfaces for the 
tools provided by de- 
fault 


ca.concordia.ciise.ftklipse.util 


Utility classes 



Table 3.2: Package organization 
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Attribute 


Type 


Summary 


id 


string 


unique identifier for the tool 


name 


string 


name of the tool. Not currently used 


class 


ITool 


class implementing our standard inter- 
face for the tool execution 


type 


enumeration 


one of collection, analysis or other. 
Used for structuring tools in menus 


parameter 


string 


for future use, allowing a tool to regis- 
ter more than once but with different 
paramters that would let it act differ- 

ciilly. 


outputfile 


string 


for future use, allowing a tool to reg- 
ister and specify a default output file 
for its operation 


category 


string 


for future use, in order to group tools 
for batch collection or batch analysis 
of data 


platform 


enumeration 


either win or imix. To specify on 
which platform the tool operates 


inBatchMenu 


boolean 


whether the plug-in requires to be reg- 
istered in batch processing menus 


inRightClickMenu 


boolean 


whether the plug- in requires to be reg- 
istered in the right-click menu 


friendlyName 


string 


short name of the tool, for displaying 
the user 


uiclass 


ITooUI 


class implementing our standard inter- 
face for the tool execution 



Table 3.3: Extension Point for Third-Party Plug-Ins 
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all tools, we used a set of registry singletons which are responsible to conserve 
single instances of the information. 

Plug-in developpers would thus find the WidgetRegistrySingleton to 
be very helpful, as it notably returns a reference to the case and evidence 
tree, which can be queried to find the active evidence and active projects. 

As such, we do not implement a strict Model- View-Controller (MVC) 
architecture, but merely a model that is similar to it, as the plug- ins are 
trusted not to modify and user interface elements. 



3.5 User Interface Design 
3.5.1 Appearance 

Ftklipse is implemented using JFace and SWT, technologies provided within 
the Eclipse framework. It consists of a single window composed of a menu 
bar on the top, a tree structure on the left-hand side, and a multiply-tabbed 
area at the centre. 

This central area displays information about the currently opened evi- 
dence file or case information from the case database. Please refer to Fig- 



ure 3.10 and Figure 3.11 for screenshots of the implementation. 
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t> ''.^ bin 
I> rj' data 

I> GxamplG_GvlclGnce 

I> Pllb 

I> '^j META-INF 

I> rGfGTGnCGS 

|> ftschGma 

^ Concordia 
^ IJPcllsG 
^ Ipftkllpse 

[> @ accesscontrol 
^ ^^databasG 
I> P adapters 
I> disconnection 
I> CS objects 
I> P reporting 
I> Ei^utll 
I> E)junlt 
^ EDtools 

I> ^^GXGCUtOrS 

I> pllnux 

I> Ipwindows 
^ E3ul 

I> factions 

I> E)tools 
I> ^utll 

> KtooJs 

Figure 3.9: Folder Structure of the Project 
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Figure 3.10: User Interface Showing the Case Introduction 
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Figure 3.11: User Interface Showing the Evidence Information and Notes 



Chapter 4 

Conclusion 



Despite the technological difficulties and limitations the chosen approach 
seems very promising. Highly modular design allows also swapping module 
implement aions from one technology to another if need be making it very 
extensible. Case management, very strong backend architecture for Tools, 
Database, and Report Generation. Eclipse UI integration are strong points 
of this project. 

4.1 Summary of Technologies Used 

The following were the most prominent technologies used throughout the 
project: 



Echpse IDE |E+n8 



• iText PDF generation library |LS06j 

• HSQLDB lighweight embedded Java SQL engine |The08] 

• Visual Editor for Eclipse |Con06e] 
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4.2 Summary of Tools Added 

The number of testing tools is not large and many more could be added 
from various resources |litt06| . however, there were enough for many test 
cases given time limitations. The following Linux tools were used for testing 
and worked: 

• stegdetect |Pro04| . stegbreak, stegdeimage, niagic2mime, 

• file, 

• strings, 

• dcfldd. 

4.3 Summary of Difficulties 

Learning curve for Eclipse plug-in and UI frameworks |Bol031 IConOGbl IGal02| 
IKi^'L02l IProOSl IBur06l ICon06fl ICon06d[ ICon06a| with large volumes of APIs 
and documentation was overwhelming at the beginning and making things 
like right- and double-click to work as well as SWT-based |Con06c] . UIs was 
sometimes non-trivial. 

4.4 Limitations and Technological Restrictions 

The Eclipse framework imposes some technological restrictions in user in- 
terface programming on two major areas that impacted our design. 

The first restriction is that the menu items are populated by 'Actions', 
and that it is impractical to have a different Action instance for each menu 
item for each possible item the menu can interact with. For example, the 
right-click menu, although capable of being dynamically generated every 
time, requires to perform an action based on the currently selected item. 
Re-creating the menu on each right-click from new objects is expensive both 
in memory and computationally, risking to create an interface with a high 
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response time to the user, which impacts negatively on usabihty. Another 
option is to create a cache of such items and change internal data members 
related to the selected widget before displaying the menu. This approach 
increases complexity and was not considered to be a good solution in our 
context, due to the complexity of propagating this strategy to existing and 
future options. Finally, we considered having a central access point to the 
information on the selected items that would be opaque to the underlying 
data types creating the tree hierarchy. This last approach, altough less 'pure' 
object-oriented design, was retained for its ease of use in prototyping new 
features, as well as the assumed atomicity of GUI operation (i.e. it should 
not be possible to change the selection while the handling of the right-click 
on the selection is running). 

The second restriction is Eclipse's all-or-nothing approach to plug-in 
development. As far as we understood the framework, it is possible to 
use Eclipse's internal data types and existing advanced widgets only when 
extending the framework in our plug-in. A plug-in that would choose not to 
follow Eclipse's organization (which is our case) could thus not have access to 
pre-existing file browsers and variety of editors. As such, the tree hierarchy, 
mouse handling, and data visualization needed to be reimplemented from 
lower-level SWT components. 

4.5 Future Work and Work-in-Progress 

Allow addition of tools dynamically though GUI Improve case management 
with full chain of custody (backend is done for this) Integration of the hex- 
adecimal editor plugin |Pal06| 
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